home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1058 < prev    next >
Internet Message Format  |  1994-08-27  |  2KB
  1. Date: Tue, 26 Jul 94 20:16 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Re: GEM apps, in general
  5. Precedence: bulk
  6.  
  7. ========================================================================
  8. It may well be a lot faster, but its hideously expensive and inefficient.
  9. The main window of my first real gem application was a scrolling CLI window,
  10. and I initially considered doing redraws by maintaining a blittable copy of
  11. ========================================================================
  12.  
  13. Of course, for something like text, an offscreen bitmap is a horrible
  14. idea.  But what about a graphics screen?  No, not GEM-objects.  Obviously,
  15. the display of a GEM IMG or XIMG file or similar file requires that you
  16. change the file to device dependant form and then blit it during redraws.
  17. Or you transform the IMG during redraw and slow it down.  Either way,
  18. you are gonna back that window via blitting.
  19.  
  20. Consider VDI calls.  Or a Metafile.  Should you save these in some
  21. command buffer and then call through the list (of indeterminate size)
  22. every time the window needs to be redrawn?   What about scrolling?
  23. You'll have to clip to a small area and call through a list of VDI commands
  24. for every click of the arrow!  If the user hold down the arrow button he'll
  25. quickly fall asleep!!
  26.  
  27. Consider a graphics terminal .. not like IGS, but better, more efficient,
  28. with the AEs active and no hacks!  It can't be done!
  29.  
  30. I say it can't be done, meaning without moving logbase, making it NVDI
  31. specific or blitting things all over the place trying to use memory.sys
  32. in a color situation (the only legal way, but its slow and you need 2
  33. blit buffers plus teh screen!).
  34.  
  35. I think there ARE places where a blit-buffer is of general use, and it
  36. would be nice to have a standard way of doing it that would work on
  37. more than one machine.  Telling people they shouldn't do it is a bit
  38. short-sighted.  
  39.  
  40.